🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 13131

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 13131"

@danegsta test failure is weird. The error is semi legitimate, but it's weird that it only failed one test and not the whole lot - https://github.com/dotnet/aspire/actions/runs/19837825119/job/56839351366?pr=13131#step:22:291 .

You can get the same error locally if you return an empty array from WithContainerFiles(). This suggest that ctx.ServerAuthenticationCertificateContext was null in one test, but not others which seems odd. I'd have expected it to be null for either all of the tests in a job, or none of the tests..

    .WithContainerFiles("/tmp", async (ctx, ct) =>
    {
        return [];
    });

@danegsta test failure is weird. The error is semi legitimate, but it's weird that it only failed one test and not the whole lot - https://github.com/dotnet/aspire/actions/runs/19837825119/job/56839351366?pr=13131#step:22:291 .

You can get the same error locally if you return an empty array from WithContainerFiles(). This suggest that ctx.ServerAuthenticationCertificateContext was null in one test, but not others which seems odd. I'd have expected it to be null for either all of the tests in a job, or none of the tests..

    .WithContainerFiles("/tmp", async (ctx, ct) =>
    {
        return [];
    });

Yeah, I need to update the handling in Aspire to skip empty results.

@afscrome the empty files behavior should be fixed in main

It feels like we should update the connection strings as well to enforce TLS IF SSL is enabled.

Got this working, although not entirely happy with two things

1. I'm somewhat lying with endpoint.TlsEnabled, using it to describe whether the TLS cert is trusted, rather than whether TLS is being used or not. And ultimately being used to decide whether we need to include TrustServerCertificate on the connection string
2. The SubscribeHttpsEndpointsUpdate implementation to ensure that we continue to include the TrustServerCertificate portion of the connection string if the dev cert is not version 6 or higher.

I was meaning to follow up with you on this; I merged #14919 recently which adds conditional expression support to reference expressions and should let you simplify the certificate support checks. I'm currently using this to control whether ,ssl=true gets added to the Redis connection string based on whether an endpoint is TLS enabled.

The main requirement to take advantage of this would be to expose a ReferenceExpression property from IDeveloperCertificateService that indicates whether the latest certificate supports loopback IPs as bool.TrueString/bool.FalseString values. Then you can gait a conditional value with something like ReferenceEcpression.CreateConditional(certificateService.SupportsLoopbackIp, bool.TrueString, ReferenceExpression.Create($"whatever is required if true"), ReferenceExpression.Create($"whatever is required if false")).

I typed that up on my phone, so apologies if any of the syntax is off.

Main idea of the conditional version of reference expressions is that it takes an IValueProvider as the conditional, a string that'll be compared case insensitively against the value, and two ReferenceExpression branches; the first is used if the values match, the second if they don't.